…rolls back if there's a failure

Use AddDistinctById() helper as used elsewhere, updated it to return the
number of items added, change base type to make more accommodating and
add optional hook to alter item on add.

Set label on AutoComplete and SearchService if not set.

Rather than iterate and read contexts, add search2 context manually as
it's a published constant

Avoids secondary DB call when it can be done in one

Avoids fat interface where both text builder and text search clients are
implemented as one, BackgroundHandler will call both but API will only
ever call 1. Also allows for separate control of Timeouts etc per client

This keeps all the logic for building payload in client, meaning the
caller doesn't need to know how this is constructed.
This should keep it simple for future BackgroundHandler consumer to
implement

We have a known format and expectation for JobIds, this more accurately
represents it compared to a string.

* Save the status provided in message if not completed, rather than
defaulting to Failed. The assumption is it would always be Failed but
this change means we reflect the actual status and could handle new ones
* Add helper for constructing pipelines, following pattern used for
other test entities.
* Update tests to use TextJobId

Shares commonalities between different handlers
* Deserialise message and log if fail
* Helper to retry or dismiss if record not known
* Set log context

This means that only valid pipelines are passed down, making calling
logic simpler. Takes into account name and config.

* Added shorter timeout for builder, as per comment on
ManifestWriteService.RegisterAndSubmitPipelineJobs()
* Renamed CreateOrUpdateJob to UpsertJob to use consistent terminology

Rather than fetch pipeline and later fetch Manifest, do it on one

Currently 2 implementations, for DLCS and TextService. Keeps a
consistent signature for updating manifests and cleanly captures logic
for applying augmentations